Detection and blocking of web trackers for mobile browsers

ABSTRACT

A method for blocking web page trackers by a web browser of a mobile device, including loading a web page on a mobile device, scanning the web page to detect scripts in the web page, for each detected script, comparing content of the script with a list of URL connections, to detect trackers present in the script, each URL connection being associated with a corresponding tracker, storing the detected trackers, displaying the stored trackers to a user, enabling a user to selectively block, via said mobile device, one or more of the displayed trackers, and reloading the web page, comprising, for each selected tracker to block, rejecting the URL connection corresponding to the selected tracker.

PRIORITY REFERENCE TO RELATED APPLICATIONS

This application claims benefit of U.S. Provisional Application No.62/517,882, entitled DETECTION AND BLOCKING OF WEB TRACKERS FOR MOBILEBROWSERS, and filed on Jun. 10, 2017 by inventors Scot Robinson, PatrickConlin, Jules Panopolous and Julie Mar-Spinola, the contents of whichare hereby incorporated by reference.

This application claims benefit of US Provisional Application No.62/480,453, entitled ADVANCED MALWARE WARNING SYSTEM AND METHOD, andfiled on Apr. 2, 2017 by inventors Scot Robinson, Patrick Conlin, JulesPanopolous, Sang Hui Michael Kim and Julie Mar-Spinola, the contents ofwhich are hereby incorporated by reference.

This application claims benefit of U.S. Provisional Application No.62/412,034, entitled ADVANCED MALWARE WARNING SYSTEM AND METHOD, andfiled on Oct. 24, 2016 by inventors Michael Godlewski, Geoffrey House,Winnie Tong, Rudolph Mutter, Bay Lee Feore, Timothy Shipman, AnthonyScherba, Lee McDole, Alexander Lin Kremer, Julie Mar-Spinola, ScotRobinson, Patrick Conlin, Jules Panopolous and Sang Hui Michael Kim, thecontents of which are hereby incorporated by reference.

This application is a continuation-in-part of U.S. patent applicationSer. No. 15/069,981, entitled MALWARE WARNING, and filed on Mar. 15,2016 by inventors Michael Godlewski, Geoffrey House, Winnie Tong,Rudolph Mutter, Bay Lee Feore, Timothy Shipman, Anthony Scherba, LeeMcDole, Alexander Lin Kremer and Julie Mar-Spinola, the contents ofwhich are hereby incorporated by reference.

U.S. patent application Ser. No. 15/069,981 claims benefit of U.S.Provisional Application No. 62/159,862, entitled SECURE BROWSERAPPLICATION, and filed on May 11, 2015 by inventors Michael Godlewski,Geoffrey House, Winnie Tong, Rudolph Mutter, Bay Lee Feore, TimothyShipman, Anthony Scherba and Julie Mar-Spinola, the contents of whichare hereby incorporated by reference.

FIELD OF THE INVENTION

The present invention relates to computer privacy.

BACKGROUND OF THE INVENTION

Web tracking is the activity of a website to track and engage itsvisitors by pushing advertising and content, and to analyze visitorbehavior. Web tracking is generally performed by software, such asJavascript, that is embedded in a web page, e.g., the Javascripts shownbelow appear in a CNN International web page. Portions of theJavascripts are underlined, showing various trackers from Twitter,Facebook, Google and many others being pushed to viewers of the webpage.

For reasons of privacy it would be of advantage to provide a user withan option to block tracking, if he prefers not to be tracked. However,the challenge to providing such an option is that when a web browseropens a web page, the browser generally does not recognize thoseportions of the page that relate to tracking; and even if the browserwere to recognize such portions, the browser would need a mechanism inplace to block them.

<script id=″js-set-epic-spec″>   (function setRefDom(win, doc,registryFile)     {var edition = ((registryFile &&registryFile.split(′_′)[0]) || ′international′).toUpperCase( ),host =doc.referrer.replace(/{circumflex over( )}http(?:s)?\:\/\/([\w\-\.]+).*$/i, ′$1′).toLowerCase( );    win[edition] = win[edition] || { };win[edition].adTargets =window[edition].adTargets || { };     if (host.search(/{circumflex over( )}([\w\-]+\.)*money\.cnn\.com$/) >= 0)      {win[edition].adTargets.refdom = ‘money’;}     else if(host.search(/{circumflex over ( )}([\w\-]+\.)*(www|us|edition|next)\.cnn\.com$/) >= 0)      {win[edition].adTargets.refdom = ′cnn′;}     else if (host ===′t.co′)       {win[edition].adTargets.refdom = ′twitter′;}     else if(host.search(/{circumflex over ( )}([\w\-]+\.)*facebook\.com$/) >= 0      {win[edition].adTargets.refdom = ′facebook′;}     else if(host.search(/{circumflex over ( )}([\w\-]+\.)*google\.\w{2,3}(\.\w\w)?$/) >= 0)      {win[edition].adTargets.refdom = ′google′;}     else      {win[edition].adTargets.refdom = ′other′;}   CNN.getRefDom =function getRefDom( )     {return win[edition].adTargets.refdom;};    if (CNN.PageParams && typeof CNN.PageParams.adkey === ′string′)      {win[edition].adTargets.adkey = CNN.PageParams.adkey;}    CNN.getAdkey = function getAdkey( ){returnwin[edition].adTargets.adkey || null;};     if(CNN.Utils.exists(CNN.contentModel.analytics.cap_topics))      {win[edition].adTargets.capTopics =CNN.contentModel.analytics.cap_topics.split(/,\s*/);}   CNN.getCapTopics= function getCapTopics( ) {var capTopics = { },i,topics;     if(Array.isArray(win[edition].adTargets.capTopics)&&CNN.Utils.exists(win[edition].adTargets.capTopics[0])&&win[edition].adTargets.capTopics[0] !== ′no-value-set′)       {topics= win[edition].adTargets.capTopics;     for (i = 0; i < topics.length;i++)       {capTopics[topics[i]] = ′cap′;}}return capTopics;};   }  (window, document, ′cnni_homepage′)); </script> <script>  CNN.adTargets = {protocol: ″non-ss1″};   CNN.AdsConfig = {    enableAdLock: false,     enableGalleryAdRefresh:true,    galleryAdClicks: 4,     amazon: {″amznkey″:″3288″},    companionAdStates: [       {       ″label″:″small″,      ″minWidth″:0},       {         ″label″:″large″,        ″minWidth″:768}],     desktopSSID:′edition.cnn.com_main_homepage′,     mobileSSID: ′edition.cnn.    com_mobile_mobileweb_homepage′,   CNN.Edition = ″international″;  CNN.EditionCookie = ″PreferredEdition″;   CNN.Features = {    enableAdsConsole: true,     enableAmazonDisplayAds: true,    enableEpicAds: true,     enableFreewheel: true,    enableGalleryAds: true,     enableGigyaLogin: true,    enableKrux: true,     enableLiveFyre: true,    enableProximic: true,     enableRubiconFastlane: true,    enableAmazonVideoAds: true,     enableChartbeat: true,    enableChartbeatMAB: true,     enableOmniture: true,    enableOptimizely: true,     enableOutbrain: true,    enableOutbrainVideoKPI: true,     enableZoneOutbrain: true,  CNN.Chartbeat ={″MABsrc″:″//static.chartbeat.com/js/chartbeat mab.js″,″src″:″//static.chartbeat.com/js/chartbeat.js″,″uid″:37612};   CNN.Host = {    assetPath: ″http://edition.i.cdn.cnn.com/.a/2.20.3″,     chrome:″//i.cdn.cnn.com/cnn″,cssPath: ″/css/2.20.3″,     domain:″http://edition.cnn.com″,     main: ″edition.cnn.com″,   sponsorContent:″http://s3.amazonaws.com/cnn-sponsored- content″,     int1:″http://edition.cnn.com″,     us: ″http://us.cnn.com″,     www:″http://www.cnn.com″}; </script>

SUMMARY

Embodiments of the present invention provide a user who is browsing aweb page with an option to selectively block trackers in the web page,if he prefers not to be tracked by certain trackers. The user's browserpresents the user with a display of trackers detected in the web page,and presents on/off controls enabling the user to turn one or more ofthe displayed trackers on and off. When the user turns off one or moreof the display trackers, the web page is reloaded without those trackersthat the user turned off.

There is thus provided in accordance with an embodiment of the presentinvention a method for blocking web page trackers by a web browser of amobile device, comprising: loading a web page on a mobile device;scanning the web page to detect scripts in the web page; for eachdetected script, comparing content of the script with a list of URLconnections, to detect trackers present in the script, each URLconnection being associated with a corresponding tracker; storing thedetected trackers; displaying the stored trackers to a user; enabling auser to selectively block, via said mobile device, one or more of thedisplayed trackers; and reloading the web page, comprising, for eachselected tracker to block, rejecting the URL connection corresponding tothe selected tracker.

There is additionally provided in accordance with an embodiment of thepresent invention a web browser on a mobile device with trackerdetection and blocking capability, comprising: a tracker detector (i)scanning a web page loaded by a web browser to detect scripts in the webpage, (ii) for each detected script, comparing the script content with alist of URL connections to detect trackers in the script, each URLconnection being associated with a corresponding tracker, and (iii)storing the detected trackers on the mobile device; and a trackerblocker (iv) displaying the stored trackers to a user, (v) enabling auser to selectively block one or more of the displayed trackers, and(vi) reloading the web page, comprising, for each selected tracker toblock, rejecting the URL connection corresponding to the selectedtracker.

There is further provided in accordance with an embodiment of thepresent invention a non-transitory computer readable medium storinginstructions, which, when executed by a processor of an electronicdevice, cause the processor to receive as input a uniform resourcelocator (URL) for a web page, in response to receiving the input URL:when a URL evaluation for the input URL resides in a cache, determinewhether the URL is deemed safe based on the cached URL evaluation, andwhen a URL evaluation for the input URL does not reside in cache:perform a URL evaluation for the input URL using one or more virusscanners, store the URL evaluation for the input URL in the cache, anddetermine whether the input URL is deemed safe based on the performedURL evaluation, when the input URL is deemed safe, load and display theweb page for the input URL, and when the input URL is not deemed safe,block the web page for the input URL from being loaded and displayed,further in response to receiving the input URL: determine whether aquality assurance (QA) check criterion is met, when the QA checkcriterion is met, send the input URL as hypertext transfer protocol(HTTP) form data to an evaluator server, in response to receiving theHTTP form data, send the input URL to an evaluator device for behavioralanalysis of the web page of the input URL, and store results of thebehavioral analysis of the web page of the input URL, received from theevaluator device, in a QA database.

There is yet further provided in accordance with an embodiment of thepresent invention a non-transitory computer readable medium storinginstructions, which, when executed by a processor of an electronicdevice, cause the processor to disable URL history logging for a webbrowser that loads and displays URL web pages, and in response toreceiving an instruction from a user to bookmark a URL: advise the userthat the bookmark will maintain a history, and prompt the user toconfirm generation of the bookmark.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be more fully understood and appreciated fromthe following detailed description, taken in conjunction with thedrawings in which:

FIG. 1 is a simplified diagram of a client-based embodiment of a malwarewarning module for URLs, in accordance with an embodiment of the presentinvention;

FIG. 2 is a simplified flowchart of a client-based method for malwarewarning for URLs, in accordance with an embodiment of the presentinvention;

FIG. 3 is a screen shot of a simple interface display in which a user isprompted to enter a URL using a keyboard, in accordance with anembodiment of the present invention;

FIG. 4 is a screen shot showing that the user has input a specificidentifier (i.e., “unknown.com”), in accordance with an embodiment ofthe present invention;

FIG. 5 is a screen shot showing a message, “This is taking longer thanexpected”, displayed while a processor is waiting for scan results, inaccordance with an embodiment of the present invention;

FIG. 6 is a screen shot of a threat level of “SAFE” for a web site, inaccordance with an embodiment of the present invention;

FIG. 7 is a screen shot of a message indicating that a “SAFE” web sitedoes not have any malicious code or phishing tactics, and the locationof the web site, in accordance with an embodiment of the presentinvention;

FIG. 8 is a screen shot of a threat level of “SUSPICIOUS” for a web siteand a location of the web site, in accordance with an embodiment of thepresent invention;

FIG. 9 is a screen shot of threat level of “DANGER” for a web site, inaccordance with an embodiment of the present invention;

FIG. 10 is a screen shot of a warning including the nature of a“DANGEROUS” threat and a location of the web site, and a control toclose the connection to the web site, in accordance with an embodimentof the present invention;

FIG. 11 is a screen shot showing a threat warning for a web pagedisplayed by a processor, requiring a user to perform a swipe gesture inorder to access a dangerous web site, in accordance with an embodimentof the present invention;

FIG. 12 is a screen shot of a swipe gesture being performed to access adangerous web site, in accordance with an embodiment of the presentinvention;

FIG. 13 is a simplified flow diagram using display screens to illustratestages of a client-based malware warning mechanism, in accordance withan embodiment of the present invention;

FIG. 14 is a simplified diagram of a middleware server-based embodimentof a malware warning system for URLs, in accordance with an embodimentof the present invention;

FIG. 15 is a simplified flowchart of a middleware server-based methodfor malware warning for URLs, in accordance with an embodiment of thepresent invention;

FIG. 16 is a simplified flow diagram using display screens to illustratestages of a middleware server-based malware warning mechanism, inaccordance with an embodiment of the present invention;

FIG. 17 is a screen shot of a “SAFE” web page with a scan results alertbar providing security evaluation information, displayed at the bottomof the page, in accordance with an embodiment of the present invention;

FIG. 18 is a screen shot of a web page with interactive browser controlsdisplayed below, in accordance with an embodiment of the presentinvention;

FIG. 19 is a screen shot of configuring security settings for a secureweb browser, in accordance with an embodiment of the present invention;

FIG. 20 is a screen shot of aggregate pass/fail scan results from aplurality of different scanners, in accordance with an embodiment of thepresent invention;

FIG. 21 is a simplified flowchart of a URL evaluation method, inaccordance with an embodiment of the present invention;

FIG. 22 is a simplified flowchart of a client-based method for malwarewarning for search results, in accordance with an embodiment of thepresent invention;

FIG. 23 is a screen shot of a warning regarding potential risks ofsearch results in accordance with an embodiment of the presentinvention;

FIG. 24 is a simplified flowchart of a middleware server-based methodfor malware warning for search results, in accordance with an embodimentof the present invention;

FIG. 25 is a simplified flow diagram using display screens to illustratestages of a middleware server-based malware warning mechanism for websearch results, in accordance with an embodiment of the presentinvention;

FIG. 26 is a screen shot of a web page with tracker detection, inaccordance with an embodiment of the present invention;

FIG. 27 is a screen shot of a message about trackers that is overlaid onthe web page of FIG. 26, in accordance with an embodiment of the presentinvention;

FIG. 28 is a screen shot of a list of trackers that are detected in theweb page of FIG. 26, in accordance with an embodiment of the presentinvention;

FIG. 29 is a screen shot of a web page with tracker detection, beforetrackers are blocked, in accordance with an embodiment of the presentinvention;

FIG. 30 is a screen shot of on/off controls for turning tracker blockingon and off, in accordance with an embodiment of the present invention;

FIG. 31 is a screen shot of a web page that is reloaded after trackersare blocked, in accordance with an embodiment of the present invention;and

FIG. 32 is a simplified flowchart of a method for tracker detection andblocking, in accordance with an embodiment of the present invention.

For reference to the figures, the following index of elements and theirnumerals is provided. Similarly numbered elements represent elements ofthe same type, but they need not be identical elements.

Table of elements in the FIGS. Element Description 100 client computingdevice 110 client processor 120 touch-enabled input/output module 125touch-based keyboard 130 web browser 140A first warning generator 140Bsecond warning generator (optional) 140C third warning generator 150 URLdatabase 160 tracker detector 170 tracker blocker 200 middleware servercomputing device 210 middleware server processor 250 URL database 260tracker database 300 virus scan engine(s) 320 evaluator server 325 QAdatabase 350 search engine(s) 410-460 display screens 510 scan resultsalert bar 521-528 browser controls 530 scan control for immediatescanning of a currently active URL page 541-546 configurable settingsfor a secure web browser

Elements numbered in the 1000's are operations of flow charts.

DETAILED DESCRIPTION

In accordance with embodiments of the present invention, modules,systems and methods are provided for protecting a user's privacy whenbrowsing a web page using a mobile phone. Embodiments of the presentinvention detect trackers that are scripted in the web page that theuser is browsing, and enable the user to selectively turn them off.

Client-Based Embodiment

Reference is made to FIG. 1, which is a simplified diagram of aclient-based embodiment of a malware warning module for URLs, inaccordance with an embodiment of the present invention. Shown in FIG. 1is a client computing device 100 with a processor 110, a touch-enabledinput/output (I/O) module 120, such as a touch screen, and a web browser130. Client 100 also includes a data bus and memory modules that storedata and instructions; the memory modules being accessible by processor110, via the data bus, for processor 110 to perform read and writeoperations.

In accordance with an embodiment of the present invention, client device100 is an electronic computing device, including inter alia mobiledevices such as smartphones, tablets, laptops, medical devices, Internetof things devices, and computers in vehicles, which have processors,memory and communication interfaces. Client device 100 may be programmedand configured to perform the methods of the present invention describedbelow. Depending on the operating system of client device 100, standardappropriate programming languages for developing and testingapplications, including application program interfaces (APIs), pop-upwindows and animations, can implement the methods of the presentinvention.

I/O module 120 provides for touch and gesture input to processor 110, inresponse to a user touching a surface of the device with an object suchas a finger, or sliding his finger along the surface of the device toperform a gesture such as the familiar “swipe” gesture. Web browser 130may be, for example, the familiar ANDROID®-based or SAFARI® web browser.

Shown in FIG. 1 are three warning generators, 140A, 140B and 140C.Operation of these warning generators is described below. Warninggenerators 140A, 140B and 140C may be three separate modules, as shownin FIG. 1, they may be combined into fewer modules, or they may beseparated into more modules. Warning generators 140A, 140B and 140C maybe software, firmware or hardware modules, or a combination of software,firmware and hardware modules.

Also shown in FIG. 1 is a URL database 150, which stores URLs and theirscan results, as described below. URL database 150 may reside locally onclient device 100, as shown in FIG. 1, or alternatively it may resideremote from client device 100.

Also shown in FIG. 1 are one or more virus scan engines 300, anevaluator server 320, a QA database 325, and one or more search engines350. Scan engine(s) 300 scan content at a designated URL location formalicious or potentially malicious malware code. Scan engine(s) 300 maybe a physical gateway capable of scanning content at a URL location,and/or may be a cloud-based content scanning service. Evaluator server320 performs behavioral analysis of web pages for quality assurance (QA)and stores results in URL database 150 and in QA database 325, asdescribed below with reference to FIG. 21. Generally, scan engine(s) 300provide only pass/fail or grade/rating information indicating a threatlevel for a URL web page, whereas evaluator server 320 performs scriptbehavioral analysis and provides security profile data including a listof suspicious operations performed by a URL web page. Behavioralanalysis results in QA database 325 are reported to an administrator.

Use of evaluator server 320 enables behavior analysis results to bestored in QA database 325 for later processing without impactingprocessing by scan engine(s) 300 in determining threat levels.

Search engine(s) 350 may be a physical or cloud-based search service,such as Microsoft BING®. Evaluator server 320 may be separate fromsearch engine(s) 350, or may be part of search engine(s) 320.

In an embodiment of the present invention, a client application ondevice 100 interacts with scan engine(s) 300 and with evaluator server220, transmitting URLs to scan engine(s) 300 and receiving malwarereports from scan engine(s) 300, and transmitting URLs to evaluatorserver 320 and receiving malware reports from evaluator server 320. Inanother embodiment of the present invention, web browser 130 is itselfconfigured to interact with scan engine(s) 300 and with evaluator server220.

Reference is made to FIG. 2, which is a simplified flowchart 1000 of aclient-based method for malware warning for URLs, in accordance with anembodiment of the present invention. Flowchart 1000 of FIG. 2 is dividedinto three columns. The left column includes operations performed by auser of client device 100, the middle column includes operationsperformed by client device 100, and the right column includes operationsperformed by scan engine(s) 300.

At the beginning of method 1000, the user is prompted to enter anidentifier, such as a URL, for accessing web content. In this regard,reference is made to FIG. 3, which is a screen shot of a simpleinterface display in which a user is prompted to enter a URL using akeyboard 125 displayed in I/O module 120, in accordance with anembodiment of the present invention. At operation 1004, the user entersan identifier for accessing content at a web site that is identified bythe identifier. In this regard, reference is made to FIG. 4, which is ascreen shot showing that the user has entered a specific identifier,namely, “unknown.com”, in accordance with an embodiment of the presentinvention.

At operation 1008, client device 100 passes the URL to scan engine(s)300 for analysis. Alternatively, instead of invoking scan engine(s) 300,client device 100 may consult URL database 150, which stores malwareinformation for each of a plurality of URLs. If the specific URL inputby the user does not reside in URL database 150, or if it does reside inURL database 150 but its information is out of date, e.g., more than 30days old, only then does client device 100 pass the URL to scanengine(s) 300 to perform a scan of the URL. When the specific URL inputby the user does reside in URL database 150 and its information is up todate, user experience and efficiencies are enhanced by avoiding a scanby scan engine(s) 300.

Operation 1008 may be performed inter alia by invoking remote orthird-party scanners, such as the VirusTotal™ scanner athttps://www.virustotal.com, using an API key. VirusTotal providessecurity results from many different scan engines. More time is requiredwhen the URL needs to be scanned, and client device 100 may display amessage to the user in response to which the user may either wait orcancel the scan. In this regard, reference is made to FIG. 5, which is ascreen shot of a message, “This is taking longer than expected”,displayed while client device 100 is waiting for scan results, inaccordance with an embodiment of the present invention.

At operation 1012, scan engines(s) 300 scan the content at the URL, andreturn the results of the scan to client device 100.

At operation 1048, warning generator 140A determines a threat level ofthe content located at the identified web site, based on the resultsreceived from scan engine(s) 300, and generates a first warningincluding the thus-determined threat level.

In accordance with one embodiment of the present invention, threatlevels are categorized as being “SAFE”, “SUSPICIOUS” and “DANGEROUS”.Reference is made to FIG. 6, which is a screen shot of a threat level of“SAFE” for the web site “unknown.com”, in accordance with an embodimentof the present invention. Reference is made to FIG. 7, which is a screenshot of a message displayed by warning generator 140B indicating thatthe “SAFE” web site does not have any malicious code or phishingtactics, and the location of the web site, in accordance with anembodiment of the present invention. FIG. 7 shows that the web site iscategorized as “technology” and resolves to a domain located in theUnited States.

Reference is made to FIG. 8, which is a screen shot of a threat level of“SUSPICIOUS” for web site displayed by warning generator 140B, includingthe nature of the “SUSPICIOUS” threat and a location of the web site, inaccordance with an embodiment of the present invention. FIG. 8 showsthat the threat is phishing malware that steals personal information,and that the web site is categorized as “news & media” and resolves to adomain located in the United States.

Reference is made to FIG. 9, which is a screen shot of a threat level of“DANGER” for the web site “unknown.com”, in accordance with anembodiment of the present invention.

At operation 1052 the user requests more information about the nature ofthe threat. At operation 1056 warning generator 140B generates a secondwarning including the nature of the threat and the location of theidentified web site. In this regard, reference is made to FIG. 10 whichis a screen shot of a warning displayed by warning generator 140B,including the nature of the “DANGEROUS” threat and a location of the website, and a control to close the connection to the web site, inaccordance with an embodiment of the present invention. SpecificallyFIG. 10 shows that the threat is phishing malware that steals personalinformation, and that the web site is categorized as “phishing”,“malware” and “malicious”, and resolves to a domain located in Russia.

At operation 1060 the user requests access to content at the identifiedweb site. If the requested content has a threat level of “DANGEROUS”,then at operation 1064, warning generator 140C prompts the user toperform a confirmatory gesture, such as a swipe gesture. Such a promptis shown in FIG. 11. Operation 1064 is performed only when the threatlevel of the identified web site is “DANGEROUS”; alternatively,operation 1064 may be performed when the threat level of the identifiedweb site is either “SUSPICIOUS” or “DANGEROUS”.

Reference is made to FIG. 11, which is a screen shot showing a threatwarning for a web site displayed by warning generator 140C, requiring auser to perform a swipe gesture in order to access a dangerous web site,in accordance with an embodiment of the present invention. FIG. 11 showsa threat warning for the web site “unknown.com” displayed by warninggenerator 140C, in accordance with an embodiment of the presentinvention. The warning includes the text “WARNING” displayed with acaution sign, and a message indicating that accessing the identified website may be harmful to device 100 or may compromise sensitiveinformation of the user. The warning also provides touch controls forthe user to “GO BACK” and not access the identified web site, or to“LEARN MORE” about the nature of the threat. If the user wishesnevertheless to access the identified web site, then the user isrequired to perform a swipe gesture on I/O module 120, to slide thewarning message off of the display.

At operation 1068 the user reviews the displayed message and decidesnevertheless to perform the confirmatory gesture. In this regard,reference is made to FIG. 12, which is a screen shot of a swipe gesturebeing performed on I/O module 120 to access the dangerous web site, inaccordance with an embodiment of the present invention. As the swipegesture is being performed and the warning message slides out of thedisplay, another message, “VISIT DANGEROUS SITE”, slides into thedisplay. As such, it will be appreciated by those skilled in the artthat it is highly unlikely that the user access the identified web siteunintentionally.

At operation 1072, in response to the user having performed theconfirmatory gesture at operation 1068, web browser 130 attempts toaccess the identified web site. However, it may be that the identifiedweb site redirects web browser 130 using a different identifier thanthat received at operation 1010. Client device 100 may register itselfto listen to redirection events for web browser 130 and, as such, isable to hook web browser 130 before it accesses the differentidentifier. At decision 1076, client device 100 determines whether ornot web browser 130 has been redirected. If so, processing returns tooperation 1008, where client device 100 passes the different identifierto scan engine(s) 300 for analysis. Otherwise, if decision 1076determines that web browser 130 has not been redirected, processingadvances to operation 1080, where web browser 130 accesses the contentthat the user requested at operation 1060. The user then views andinteracts with the content at operation 1084, thereby completingflowchart 1000.

In an alternative embodiment of the present invention, warning generator140B of FIG. 1 may be eliminated and, correspondingly, method 1000 ofFIG. 2 may advance directly from operation 1048 to operation 1060. Assuch, the tri-warning module, system and method of FIGS. 1 and 2 mayoptionally be a bi-warning module, system and method, respectively,without using the intermediate informational warnings, such as thewarnings shown in FIGS. 7, 8 and 10. Instead, after displaying thethreat level (first warning) of an identified web site at operation1048, if the threat level is “DANGEROUS” the user is required to performa confirmatory gesture in order to access the site (second warning) atoperation 1068. To indicate this alternative embodiment, warninggenerator 140B is drawn with a dashed rectangle in FIG. 1, operations1052 and 1056 are drawn with dashed rectangles in FIG. 2, and an arrowfrom operation 1048 to operation 1060 is drawn with a dashed line inFIG. 2.

There are many ways to classify malware threats based on scan resultsfrom scan engine(s) 300. Inter alia classification of malware threats bywarning generator 140A into types “DANGEROUS”, “SUSPICIOUS” and “SAFE”may be based on statistics of the virus scan results provided to warninggenerator 140A from scan engine(s) 300. In one exemplary embodiment,categorization may be based on statistical conditions such as thoseshown in TABLE I below.

TABLE I Statistical breakdown of scan engine results into threat levelsThreat Type Condition DANGEROUS >75% of the scan engines indicate riskSUSPICIOUS 5%-75% of the scan engines indicate risk SAFE <5% of the scanengines indicate riskIn another exemplary embodiment, the scan engine(s) 300 may providetheir own results that can be mapped to the “DANGEROUS”, “SUSPICIOUS”and “SAFE” trichotomy, and categorization may be based on statisticalconditions such as those shown in TABLE II below.

TABLE II Statistical breakdown of scan engine results into threat levelsThreat Type Condition DANGEROUS at least 2 of the scan engine resultsmap to DANGEROUS, or 1 scan engine result maps to DANGEROUS and 1 scanengine result maps to SUSPICIOUS. SUSPICIOUS at least 2 of the scanengine results map to SUSPICIOUS. SAFE At most 1 of the scan engineresults map to DANGEROUS or SUSPICIOUS.Those skilled in the art will appreciate that TABLES I and II are merelyexemplary. The present invention anticipates other classifications basedon scan results from scan engine(s) 300.

Reference is made to FIG. 13, which is a simplified flow diagram usingdisplay screens to illustrate stages of a client-based malware warningmechanism, in accordance with an embodiment of the present invention.FIG. 13 includes virus scan engine(s) 300. Screen 410 is a landingscreen, e.g., the screen shown in FIG. 3, prompting a user to enter aURL. Screen 420 is a loading screen, e.g., the screen shown in FIG. 4.While screen 420 is being displayed, warning generator 140A determinesthe security threat of the URL that was entered in screen 410. Ifsecurity information for the URL is not readily available in URLdatabase 150, then client device 100 queries scan engine(s) 300 forinformation about the URL. After determining the security threat,warning generator 140A displays either a “DANGEROUS” screen 431, e.g.,the screen shown in FIG. 6, or a “SUSPICIOUS” screen 432, e.g., thescreen shown in FIG. 8, or a “SAFE” screen 433, e.g., the screen shownin FIG. 10.

Client device 100 then performs the warning method of FIG. 2 beginningat operation 1055. Upon request by the user of information about thenature of the threat, warning generator 140B generates warning screens,such as the screens shown in FIGS. 7, 9 and 11, with warning informationfor the respective “DANGEROUS”, “SUSPICIOUS” and “SAFE” threat levels.

If the user decides to access the content at the URL, then warninggenerator 140C requires that the user perform a confirmatory gesture, asshown in FIG. 11. Upon performing the confirmatory gesture, web browser130 attempts to access the URL. If web browser is re-directed to anotherURL, then client device 100 hooks the re-direction event and displaysscreen 420, prior to web browser 130 accessing the other URL.

Middleware Server-Based Embodiment

Reference is made to FIG. 14, which is a simplified diagram of amiddleware server-based embodiment of a malware warning system for URLs,in accordance with an embodiment of the present invention. As shown inFIG. 14 middleware server 200 intermediates between client device 100and scan engine(s) 300.

In an embodiment of the present invention, a client application ondevice 100 interacts with middleware server 200, transmitting URLs tomiddleware server 200 and receiving malware reports from middlewareserver 200. In another embodiment of the present invention, web browser130 is itself configured to interact with middleware server 200.

It will be appreciated by those skilled in the art that a client-serverarchitecture affords many variations in distribution of processing laborbetween the client and the server, all of which are contemplated by thepresent invention. Thus, comparing FIG. 14 to FIG. 1, in FIG. 14middleware server 200, instead of client device 100, passes URLs to scanengine(s) 300 and to evaluator server 320. In alternative embodiments,however, middleware server 200, instead of client device 100, may passURLs to the Internet, and/or may pass search terms to search engine 350.Similarly, one or more of the three warning generators 140A, 140B and140C may be components of middleware server 200 instead of client device100.

Middleware server 200 contains a URL database 250, which stores URLs andtheir scan results. URL database 250 may reside locally on middlewareserver 200, as shown in FIG. 14, or alternatively it may reside remotefrom middleware server 200.

Web browser 130 includes a tracker detector 160 that detects web pagetrackers, and a tracker blocker 170 that blocks web page trackers, andmiddleware server includes a tracker database 260 that stores knowntrackers. Operation of tracker detector 160 and tracker blocker 170, anduse of tracker database 260 is described below with reference to FIGS.26-32.

Reference is made to FIG. 15, which is a simplified flowchart 1100 of amiddleware server-based method for malware warning for URLs, inaccordance with an embodiment of the present invention. Flowchart 1100of FIG. 15 is divided into four columns. The left-most column includesoperations performed by a user of client device 100, thesecond-from-leftmost column includes operations performed by clientdevice 100, the second-from rightmost column indicates operationsperformed by middleware server 200, and the rightmost column, at thetop, includes operations performed by scan engine(s) 300 and, at thebottom, includes operations performed by evaluator server 320.

At operation 1104, the user enters an identifier, such as a URL, foraccessing content at a web site identified by the identifier. Atoperation 1108, client device 100 passes the identifier to middlewareserver 200 for analysis, thereby relieving client device 100 from thistask. At decision 1112, middleware server 200 consults URL database 250to determine if information about the URL already resides in URLdatabase 250, and if this information has not expired. An expirationdate, e.g., 30 days, is pre-configured, so as to force re-scans of URLsafter a time period. If decision 1112 is affirmative, then method 1100advances to operation 1128. Otherwise, if decision 1112 is negative,then at operation 1116 middleware server 200 passes the identifier toscan engine(s) 300 for analysis.

At operation 1120, scan engine(s) 300 scan the identified content forpotential malware, and return scan results to middleware server 200. Atoperation 1124, middleware server 200 saves the scan results in URLdatabase 250. At operation 1128, middleware server 200 evaluates thescan results that it received from scan engine(s) 300, and determines athreat level of the identified content. E.g., in one embodiment of thepresent invention, there are three threat levels; namely, “SAFE”,“SUSPICIOUS” or “DANGEROUS”. Determination of threat level may be basedon statistics of the scan results, as described hereinabove withreference to TABLES I and II. At operation 1132, middleware server 200passes a malware including the threat level to client device 100.

At operation 1136, middleware server 200 sends the identifier toevaluator server 320 at each N^(th) pass through operation 1136; e.g.,at each 4^(th) pass. Operation of evaluator server 320 is describedbelow with reference to FIG. 21. At operation 1140 evaluator server 320performs a behavioral analysis for the content identified by the URL,and returns its results to middleware server 300. At operation 1144,middleware server 200 updates the URL database 250 with the results itreceives from evaluator server 320.

Subsequent operations 1148-1184 are similar to correspondingly numberedoperations 1048-1084, which are described above with reference to FIG.2.

Reference is made to FIG. 16, which is a simplified flow diagram usingdisplay screens to illustrate stages of a middleware server-basedmalware warning mechanism, in accordance with an embodiment of thepresent invention. FIG. 16 includes middleware server 200 and scanengine(s) 300. Screen 410 is a landing screen, e.g., the screen shown inFIG. 3, prompting a user to enter a URL. Screen 420 is a loading screen,e.g., the screen shown in FIG. 4. While screen 420 is being displayed,device 100 sends the URL that was entered in screen 410 to middlewareserver 200 for analysis. If security information for the URL is notreadily available to middleware server 200 in URL database 250, or ifthe information is available but out-of-date, then middleware server 200queries scan engine(s) 300 for information about the URL. After clientdevice 100 receives a threat level for the URL from middleware server200, warning generator 140A displays either a “SAFE” screen 431, e.g.,the screen shown in FIG. 6, or a “SUSPICIOUS” screen 432, e.g., thescreen shown in FIG. 8, or a “DANGEROUS” screen 433, e.g., the screenshown in FIG. 10, based on the threat level of the identified content.

Client device 100 then performs the warning method of FIG. 16 beginningat operation 1156. Optionally, upon request by the user of informationabout the nature of the threat, warning generator 140B generates warninginformation, such as the information shown in FIGS. 7, 8 and 10 for therespective “SAFE”, “SUSPICIOUS” and “DANGEROUS” threat levels.

If the user decides to access the content at the URL, and if thatcontent has a threat level of “DANGEROUS”, then warning generator 140Crequires that the user perform a confirmatory gesture. Upon performingthe confirmatory gesture, web browser 130 attempts to access the URL. Ifweb browser is re-directed to another URL, then client device 100 hooksthe re-direction event, and reports the re-direction event to middlewareserver 200, which then analyzes the other URL.

Reference is made to FIG. 17, which is a screen shot of a “SAFE” webpage with a scan results alert bar 510 providing security evaluationinformation, displayed at the bottom of the page, in accordance with anembodiment of the present invention. When a page is loaded, scan resultsalert bar 510 is displayed and remains displayed for a pre-configuredamount of time. In accordance with an embodiment of the presentinvention, by pressing on results alert bar 510 the user is able torequest display of the complete scan results for the URL.

Reference is made to FIG. 18, which is a screen shot of a web page withinteractive browser controls displayed below, in accordance with anembodiment of the present invention. FIG. 18 shows a control 521 fortabbing through URL pages, a control 522 for configuring settings, acontrol 523 for bookmarking a currently active URL page and opening abookmarked page, a control 524 for viewing and accessing a browsinghistory, a control 525 for recommending a currently active URL page, acontrol 526 for rating a currently active URL page, a control 527 forhelp, a control 528 for information about a browser that is currentlybeing used, and a control 529 for sending the currently active URL page.FIG. 19 also shows a control 530 for forcing an immediate scan of acurrently active URL page.

Reference is made to FIG. 19, which is a screen shot of configuringsecurity settings for a secure web browser, in accordance with anembodiment of the present invention. FIG. 19 shows a setting 541 forturning the URL scanning on and off. FIG. 19 also shows a setting 542for turning on and off private browsing; i.e., browsing without storinga history log. When private browsing is turned on, and a user attemptsto set a bookmark, the user is asked to confirm that he wishes to setthe bookmark since it will leave a history of a web site that hevisited.

FIG. 19 also shows a setting 543 for turning on and off an audible alertfor dangerous web pages. FIG. 19 also shows a control 544 forconfiguring an amount of time that scan results bar 510 (FIG. 17)remains displayed. FIG. 19 also shows a setting 545 for turning touchidentification on and off. FIG. 19 also shows a setting 546 for turningpasscode protection on and off.

URL Behavioral Analysis

Scan engine(s) 300 may provide only pass/fail information, orgrade/rating information indicating a level of risk for URL content.Reference is made to FIG. 20, which is a screen shot of aggregate scanresults from a plurality of different scanners, in accordance with anembodiment of the present invention.

In distinction, evaluator server 320 performs script behavioral analysisand provides security profile data including a list of suspiciousoperations performed by a URL web page. However, such analysis is moretime-consuming that the scans performed by scan engine(s) 300, and it isgenerally unfeasible for a browser to perform such analysis in-line,since the longer response time for loading and displaying URL content toa user would overburden and frustrate the user.

Instead, embodiments of the present invention provide behavioralanalysis off-line, non-synchronous with scan engine(s) 300, so as not tointerfere with the user's browsing experience. The results of thebehavioral analysis are stored in QA database 325, and provided to theuser or to an administrator automatically, or upon request.

Reference is made to FIG. 21, which is a simplified flowchart of a URLevaluation method 1200, in accordance with an embodiment of the presentinvention. At operation 1205, a user enters a URL as input to clientdevice 100. Alternatively, client device 100 may receive a URL fromsearch engine(s) 350 in response to one or more search terms entered bythe user. At decision 1210, a determination is made whether the URLrequires evaluation. Inter alia the determination at operation 1210 maybe made by checking if the URL is listed in a “black list” ofpotentially malicious URLs, in which case the URL is deemed to requireevaluation. Alternatively, the determination at operation 1210 may bemade by checking if the URL is listed in a “white list” of trusted URLs,in which case the URL is deemed to not require evaluation. Yetalternatively, a URL may be deemed to not require evaluation if the URLis in a browsing history, and has been there for the past N days, whereN is a pre-configured number.

If it is determined at decision 1210 that the URL does not requireevaluation, then at operation 1215 the content linked to by the URL isloaded into client device 100. Otherwise, if it is determined atoperation 1210 that the URL does require evaluation, then at operation1220 the URL is sent to a middleware server such as middleware server200.

At decision 1225 the middleware server determines if the URL resides inURL database 250, which stores URLs and their scan results, and if theURL information has not expired. If it is determined at decision 1225that the URL does not reside in URL database 250 or that the URL doesreside in URL database 250 but its information has expired, then atoperation 1230 the URL is sent to a security scanner for securityevaluation. At decision 1235 a determination is made whether or not theURL is safe. If it is determined at operation 1235 that the URL is safe,then control proceeds to operation 1215 where the content linked to bythe URL is loaded into client device 100. Otherwise, if it is determinedat decision 1235 that the URL is not safe, then the URL is blocked atoperation 1240.

If it is determined at operation 1225 that the URL does reside in URLdatabase 250 and its information has not expired, then control proceedsdirectly from operation 1225 to operation 1235, bypassing the scan atoperation 1230. It will be appreciated by those skilled in the art thatbypassing the scan eliminates time-consuming processing, and acceleratesmethod 1200. It will be further appreciated by those skilled in the artthat URL database 250 may be configured to delete old URLs that have notbeen recently scanned, e.g., URLs that have not been scanned within thepast 30 days, in order to cause method 1200 to re-scan such URLs.

Returning to operation 1210, if it is determined at operation 1210 thatthe URL does require evaluation, then at operation 1240 a determinationis made whether one or more quality assurance (QA) sample check criteriaare met. E.g., every 4^(th) URL may be selected for QA testing;alternatively, selection may be random. If it is determined at operation1240 that the one or more QA criteria are met, then at operation 1245the URL is sent to evaluator server 320 as HTTP form data, forperformance of behavioral analysis on the URL page.

At operation 1250 the evaluator server sends the URL to one or moreevaluator devices. At operation 1255 the one or more evaluator devicesevaluate behavior of the URL content, e.g., by deriving a list ofsuspicious operations performed by the URL content. At operation 1260the results of the evaluation are stored URL database 250. Optionally,the results of the evaluation may be stored in QA database 325, foraccess by an administrator. Operations 1240-1260 ensure that thebehavior analysis by evaluator server 330 and storing of behaviorinformation in URL database 250 are performed separate from the scanningfor risk assessment at operation 1230, thus avoiding any degradation ofthe user's web browsing experience.

Malware Warnings for Search Results

It will be appreciated by those skilled in the art that the warningmodules, systems and methods of the present invention are of widespreadadvantage to many client-server applications. In some embodiments, thepresent invention is applied to search engines, to provide warningmodules, systems and methods for potential malware in web searchresults. These applications may be embodied inter alia with or withoutuse of a middleware server computer.

Reference is made to FIG. 22, which is a simplified flowchart 1300 of aclient-based method for malware warning for search results, inaccordance with an embodiment of the present invention. Flowchart 1300of FIG. 22 is divided into four columns. The leftmost column includesoperations performed by a user, the second-from-leftmost column includesoperations performed by client device 100, the second-from rightmostcolumn indicates operations performed by search engine(s) 350, and therightmost column includes operations performed by scan engine(s) 300.

At operation 1304, the user enters either an identifier, such as a URL,or a search term. At decision 1308, client device 100 determines whetheror not the user entered a search term. For example, client device 100may examine the text string input by the user for the presence of adomain name extension such as “.com”. If decision 1308 determines thatthe user did not enter a search term, then the user input is anidentifier, and at operation 1312 flowchart 1200 advances to operation1008 of FIG. 2; namely, a method for malware warning for identifiers.

If decision 1308 determines that the user entered a search term, then atoperation 1316 client device 100 passes the search term to searchengine(s) 350. At operation 1320 search engine(s) 350 perform therequested search and return their search results to client device 100.At operation 1324 client device 100 in turn passes a batch of the searchresults to scan engine(s) 300, for inspection of each result forpotential malware. Search results are sent to scan engine(s) 300 inbatches, since there may be a large number of results, and it is notnecessary for client device 100 to wait for scan engine(s) 300 to scanall of the results before presenting some of the results to the user.Each batch may be inter alia a display page worth of results. Atoperation 1328 scan engine(s) 300 analyze the batch of search resultsand return their results to client device 100.

At operation 1348, warning generator 140A determines the threat levelsof the search result content, e.g., “SAFE”, “SUSPICIOUS” or “DANGEROUS”;and displays a list of the search results in the batch together with thethreat levels of content located at each result. Reference is made toFIG. 23, which is a screen shot of a warning regarding potential risksof search results in accordance with an embodiment of the presentinvention.

At operation 1352, the user optionally requests more information aboutthe nature of the threat for one or more of the search results in thelist; e.g., the result marked “CAUTION” in FIG. 23. At operation 1356,warning generator 140B displays information about the nature of thethreat and/or the location of the one or more search results.

At operation 1360, after having seen the information displayed bywarning generator 140B, the user requests access to one of the searchresults. At operation 1364, warning generator 140C displays a warninginstructing the user to perform a confirmatory gesture, such as a swipegesture, to confirm his request, for results that have a threat level of“DANGEROUS”. At operation 1368, the user performs the confirmatorygesture.

At operation 1372, in response to the user having performed theconfirmatory gesture at operation 1368, web browser 130 attempts toaccess the requested search result. However, it may be that therequested search result redirects web browser 130 to a different website. Client device 100 may register itself to listen to redirectionevents for web browser 130 and, as such, is able to hook web browser 130before it accesses the different web site. At decision 1376, clientdevice 100 determines whether or not web browser 130 has beenredirected. If so, processing returns to operation 1008 of FIG. 2, whereclient device 100 passes an identifier for the redirected web site toscan engine(s) 300 for analysis. Otherwise, if decision 1376 determinesthat web browser 130 has not been redirected, processing advances tooperation 1380, where web browser 130 accesses the content that the userrequested at operation 1360. The user then views and interacts with thecontent at operation 1384, thereby completing flowchart 1300.

Reference is made to FIG. 24, which is a simplified flowchart 1400 of amiddleware server-based method for malware warning for search results,in accordance with an embodiment of the present invention. The flowchartof FIG. 24 is divided into five columns. The leftmost column indicatesoperations performed by a user, the second-from-leftmost columnindicates operations performed by client device 100, the middle columnindicates operations performed by search engine(s) 350, thesecond-from-rightmost column indicates operations performed bymiddleware server 200, and the rightmost column indicates operationsperformed by scan engine(s) 300.

At operation 1404 the user enters either an identifier for web content,or a search term. At decision 1408 client device 100 determines whetheror not the user entered a search term. Decision 1408 may be performed asdescribed above with reference to decision 1308 of FIG. 23. If decision1408 determines that the user did not enter a search term, then atoperation 1412 flowchart 1400 advances to operation 1108 of FIG. 15;namely, a method for malware warning for identifiers.

Otherwise, if decision 1408 determines that the user did enter a searchterm, then at operation 1416 device 100 passes the search term to searchengine(s) 350. At operation 1420 search engine(s) 350 perform theirsearch and return their search results to device 100. At operation 1424client device 100 receives the search results, but prior to displayingthem to the user, client device 100 passes a batch of the search resultsto middleware server 200 for a malware check.

At operation 1428 middleware server 200 passes the batch of searchresults to scan engine(s) 300 for scanning. At operation 1432, scanengine(s) 300 scan the batch of search results, and return scan resultsto middleware server 200. At operation 1436 middleware server 200determines the threat level of each search result based on the scanresults received from scan engine(s) 300, and passes malware reportswith the threat levels back to client device 100.

Subsequent operations 1448-1484 are similar to correspondingly numberedoperations 1348-1384 of FIG. 22.

In accordance with an alternative embodiment of the present invention,middleware server 200, instead of client device 100, passes the searchterms to search engine(s) 350. In this case, instead of operation 1424,namely, client device 100 passing the search results to middlewareserver 200 subsequent to operation 1420, instead client device 100instead passes the search terms to middleware server 200 prior tooperation 1420, and then middleware server 200 passes the search resultsto search engines(s) 350 and receives the search results from searchengine(s) 350.

Reference is made to FIG. 25, which is a simplified flow diagram usingdisplay screens to illustrate stages of a middleware server-basedmalware warning mechanism for web search results, in accordance with anembodiment of the present invention. FIG. 25 includes middleware server200, scan engine(s) 300 and search engine(s) 350. Screen 440 is alanding screen, prompting a user to enter a search expression. Screen450 is a loading screen. While screen 450 is being displayed, clientdevice 100 sends the search expression that was entered in screen 410 tosearch engine(s) 350. After receiving a page of search results, clientdevice 100 sends the results to middleware server 200, which sends theURLs of the search results to scan engine(s) 300 for analysis.Middleware server 200 determines the threat levels of the search resultsbased on the scan results, and returns malware reports including thethreat levels to client device 100. Warning generator 140A displays alist of results together with their levels of threat, as shown in screen460.

If the user touches one of the results to request information about thenature of the threat, then client device 100 performs the warning methodof FIG. 2 beginning at operation 1056, and warning generator 140Bgenerates warning information, such as the information shown in FIGS. 7,8 and 10 for the respective “SAFE”, “SUSPICIOUS” and “DANGEROUS” threatlevels.

Thus it will be appreciated by those skilled in the art that the presentinvention prevents a “one touch too late” catastrophe and ensures that auser does not access suspect malware unintentionally, by providemultiple warnings about specific malware that a user is encountering,and by requiring a confirmatory action from the user that is differentthan a simple touch, prior to accessing a suspicious web site,application or file. The present invention has widespread application tomalware protection for computing devices that receive data over anetwork.

It will be appreciated by those skilled in the art that there are manyapparent variations of the modules, systems and methods described above.The operations in the flowcharts of FIGS. 2, 15, 21, 22 and 24 may beperformed in a different order than that shown in the flowcharts. Forexample, referring to FIG. 15, the middleware server may performoperations 1136 and 1144 prior to performing operations 1128 and 1132,or between performance of operations 1128 and 1132.

Tracker Detection and Blocking

Embodiments of the present invention provide a user who is browsing aweb page with an option to selectively block trackers in the web page,if he prefers not to be tracked by certain trackers. The user's browserpresents the user with a display of trackers detected in the web page,and presents on/off controls enabling the user to turn one or more ofthe displayed trackers on and off. When the user turns off one or moreof the displayed trackers, the web page is reloaded without thosetrackers that the user turned off.

Reference is made to FIG. 26, which is a screen shot of a web page withtracker detection, in accordance with an embodiment of the presentinvention. The web page includes trackers, and a control 610 indicatesthat 34 trackers have been detected in the web page.

Reference is made to FIG. 27, which is a screen shot of a message abouttrackers that is overlaid on the web page of FIG. 26, in accordance withan embodiment of the present invention. The message instructs a user topress on control 610 to see a list of the trackers.

Reference is made to FIG. 28, which is a screen shot of a list oftrackers that are detected in the web page of FIG. 26, in accordancewith an embodiment of the present invention. The list includesadvertising trackers including Amazon.com, and analytics trackersincluding Google Tag services. The list is displayed in response to auser pressing control 610. The trackers are categorized into categoriesincluding (i) advertising trackers, (ii) analytics trackers, (iii)content trackers, and (iv) social trackers. Alongside each listedtracker is an on/off control 620 for selectively blocking the tracker.Those trackers selected to block, namely, Krux, Moat, Rapleaf, etc., aredisplayed with strikethrough text.

Reference is made to FIG. 29, which is a screen shot of a web page withtracker detection, before trackers are blocked, in accordance with anembodiment of the present invention. The web page includesadvertisements, and control 610 shows that 39 trackers on the web pagehave been detected.

Reference is made to FIG. 30, which is a screen shot of on/off controls620 for turning tracker blocking on and off, in accordance with anembodiment of the present invention. The blocked trackers, namely,Amazon.com, Casale Media, Krux, etc., are displayed with astrikethrough.

Reference is made to FIG. 31, which is a screen shot of a web page thatis reloaded after trackers are blocked, in accordance with an embodimentof the present invention. The web page in FIG. 31 is from the samewebsite as the web page of FIG. 29, but is reloaded by the web browserwithout the various trackers that were present in FIG. 29.

Reference is made to FIG. 32, which is a simplified flowchart of amethod for tracker detection and blocking, in accordance with anembodiment of the present invention. The flowchart of FIG. 32 is dividedinto two columns, the left column indicating operations performed bytracker detector 160, and the right column indicating operationsperformed by tracker blocker 170. Prior to operation 1510, web browser130 loads a full web page. For an Android operating systemimplementation, tracker detector 160 may call a method didFinishLoading() to confirm that the web page is fully loaded. For an iOS operatingsystem implementation, tracker detector 160 may call a methodwebViewDidFinishLoad( ) to confirm that the web page is fully loaded.

At operation 1510 tracker detector 160 scans the loaded web page todetect the presence of scripts in the loaded web page. For an Androidoperating system implementation, tracker detector 160 may call a methodevaluateJavascript( ) to scan all Javascript present in the web page,one at a time. Method evaluateJavascript( ) belongs to classandroid.WebviewClient. For an iOS operating system implementation, theinnerHTML of the page may be read, and script tags may be found usingclass NSScanner.

At operation 1520 tracker detector 160 compares the URL content of eachdetected script with a list of known tracker URL connections, to detectthe trackers in each script. The list of known URL tracker connectionsmay be stored in tracking database 260, and updated from time to time.In accordance with an embodiment of the present invention, the trackerdata in tracking database 260 is downloaded to client computer 100 eachtime web browser 130 is launched. Whenever URL content of a detectedscript matches a known URL connection in tracking database 260, atracker count is incremented. The tracker count is displayed insidecontrol 610, as shown in FIGS. 27 and 30. A sample list of known URLconnections is available from Disconnect, Inc. of San Francisco, Calif.athttps://raw.githubusercontent.com/disonnectme/disconnect-tracking-protection/master/services.json

At operation 1530 tracker detector 160 stores the detected trackers, sothat they may be accessed by tracker blocker 170.

At operation 1540 tracker blocker 170 displays the trackers that werestored by tracker detector 160 at operation 1530, in a presentation suchas that shown in FIG. 30, where each stored tracker is displayed with acorresponding on/off control 620. The display may organize the displayedtrackers by category including a category of advertising trackers, acategory of analytics trackers, a category of content trackers, and acategory of social trackers.

At operation 1550 tracker blocker 170 enables a user to selectivelyblock one or more of the displayed trackers by means of controls 620.The user may block individual trackers one by one, or may block anentire category of trackers at once, such as blocking all advertisingtrackers. In an embodiment of the present invention user blockingselections are preserved, and when a tracker is blocked on a specificweb page, it remains blocked on all web pages that the user visits,until the user unblocks the tracker.

It has been found that blocking of some trackers may prevent a web pagefrom fully loading. For example, the formatting of a web page may dependon a tracker, and if the tracker is blocked then the web page may notfully load. In accordance with an embodiment of the present invention, awhite list of non-blockable trackers is maintained, in order to avoidsuch a situation where a web page does not load. The white list isloaded into client computer device 100 upon launch of web browser 130,and overrides the list of trackers in tracker database 260.Specifically, the URL connections corresponding to the non-blockabletrackers in the white list are ignored at operation 1520. As such, thenon-blockable trackers in the white list are not stored at operation1530 and not displayed to the user at operation 1540.

At operation 1560 tracker blocker 170 reloads the web page, rejectingthe URL corresponding to each tracker that the user selected to block.For an Android operating system implementation, tracker blocker 170 maycall a method shouldInterceptRequest( ) for each URL that is loaded.Method shouldInterceptRequest( ) belongs to class android.WebviewClient,and is operative to intercept a URL connection, and to either accept orreject the connection. If a URL connection is selected for blocking,then the URL connection is rejected using this method. For an iOSoperating system implementation, tracker blocker 170 may call a similarmethod in class NSURLProtocol.

In the foregoing specification, the invention has been described withreference to specific exemplary embodiments thereof. It will, however,be evident that various modifications and changes may be made to thespecific exemplary embodiments without departing from the broader spiritand scope of the invention. Accordingly, the specification and drawingsare to be regarded in an illustrative rather than a restrictive sense.

What is claimed is:
 1. A method for blocking web page trackers by a webbrowser of a mobile device, comprising: loading a web page, by a webbrowser on a mobile device; scanning the web page by the web browser todetect scripts in the web page; for each detected script, comparingcontent of the script with a list of URL connections by the web browser,to detect trackers present in the script, each URL connection beingassociated with a corresponding tracker; storing the detected trackersby the web browser; displaying the stored trackers to a user by the webbrowser, wherein each stored tracker is displayed with a correspondingon/off control, and wherein the display organizes the displayed trackersby category, including a category of advertising trackers, a category ofanalytics trackers, a category of content trackers, and a category ofsocial trackers; enabling a user to selectively block, by the webbrowser, one or more of the displayed trackers; and in response to theuser selectively blocking one or more of the displayed trackers,automatically reloading the web page by the web browser, comprising, foreach selected tracker to block, rejecting the URL connectioncorresponding to the selected tracker.
 2. The method of claim 1 furthercomprising maintaining a list of trackers known to prevent saidreloading from being completed, wherein said comparing content of thescript comprises ignoring URL connections in the list of URL connectionsthat correspond to the trackers known to prevent, thereby preventingsaid storing and said displaying from respectively storing anddisplaying the trackers that are known to prevent.
 3. The method ofclaim 1 wherein said rejecting the URL connection comprises interceptingthe URL connection corresponding to the selected tracker during saidreloading of the web page.
 4. The method of claim 1 further comprisingrecording, on the mobile device, the user's selections of trackers toblock, and persisting those selections when the web browser loadsanother web page.
 5. A mobile device comprising: a touch screen enablinga user to interactively request a web page hosted on a remote web site,via a web browser in the mobile device, and enabling the mobile deviceto display the requested web page when the web page is loaded by the webbrowser; a web browser comprising: a tracker detector (i) scanning a webpage requested by the user via said touch screen and loaded by the webbrowser, to detect scripts in the web page, (ii) for each detectedscript, comparing the script content with a list of URL connections todetect trackers in the script, each URL connection being associated witha corresponding tracker, and (iii) storing the detected trackers on themobile device; and a tracker blocker (iv) displaying the stored trackersto the user via said touch screen, wherein each stored tracker isdisplayed with a corresponding on/off control, and wherein the displayorganizes the displayed trackers by category, including a category ofadvertising trackers, a category of analytics trackers, a category ofcontent trackers, and a category of social trackers, (v) enabling a userto selectively block one or more of the displayed trackers via saidtouch screen, and (vi) in response to the user selectively blocking oneor more of the displayed trackers, automatically reloading the web page,comprising, for each selected tracker to block, rejecting the URLconnection corresponding to the selected tracker.
 6. The mobile deviceof claim 5, wherein said tracker blocker (vii) records, on the mobiledevice, the user's selections of trackers to block, and (viii) persiststhose selections when said web browser loads another web page requestedby the user via said touch screen.